home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / tsql.mail / 000168_"CRLV01::HKUCE…ORION.GOV.BC.CA_Wed Jul 14 17:29:06 1993.msg < prev    next >
Text File  |  1996-01-31  |  5KB  |  107 lines
  1.  
  2.     I have included the news release as an attachment. If you could distribute it 
  3.     on to the TSQL group that would be great.
  4.  
  5.     Henry Kucera
  6.     Geomatics Unit 
  7.     Ministry of Environment Lands and Parks
  8.     British Columbia
  9.     Inter:    Hkucera@venus.gov.bc.ca
  10.       
  11.     --------------------------------------------------------------------------------
  12.  
  13.     ISO acceptance of Canadian SQL3 Multi-Media 'Spatial' Proposal
  14.  
  15.  
  16.     The third generation of SQL is currently being developed, under the
  17.     auspices of the International Organization for Standardization (ISO).
  18.      
  19.     Scheduled for the 1996 timeframe, this version: (1) will have object
  20.     oriented capabilities, (2) will be backwardly compatible with SQL 1992
  21.     (SQL2 was officially adopted last year), and (3) will have extensions
  22.     for certain application areas, including management of spatial data.
  23.      
  24.     The Geomatics Unit of the Surveys and Resources Mapping Branch, British
  25.     Columbia Ministry of Environment, Lands and Parks submitted a series of
  26.     four papers on behalf of Canada for consideration by the ISO database
  27.     language Multi-Media working group.  Included in this submission was a
  28.     framework for the development of Part 3 of SQL3/MM based directly on the SAIF
  29.     standard.  This proposal was accepted and will be the basis for all future ISO
  30.     work regarding spatial-temporal data management in SQL3/MM.
  31.      
  32.     The thrust of our submissions was fourfold.
  33.      
  34.     1    Traditional approaches to managing spatial data are inadequate
  35.          because such data is inherently complex and highly variable in
  36.          structure.  This is why almost all spatial data is stored outside
  37.          of DBMSs today.  Ideally, all data of interest to the user should
  38.          be able to be described, stored and accessed in the same fashion.
  39.          New technologies, based on object oriented capabilities, are
  40.          required.
  41.      
  42.     2    The underlying capabilities of SQL3 must be sufficiently robust to
  43.          support the extensions proposed for SQL/MM.  This means that
  44.          various kinds of aggregate structures, object capabilities and the
  45.          like must be present in the basic SQL3 infrastructure.  The same
  46.          underlying constructs should be applicable to animation, spatial
  47.          and temporal phenomena, full text, etc., as well as more
  48.          traditional application areas.
  49.      
  50.     3    Spatial extensions should not be tied to a cartographic (static,
  51.          2-D representational) paradigm.  Volumetric and temporal data must
  52.          be able to be handled, as well as a variety of spatial and
  53.          temporal relationships.  In addition to forestry data, census
  54.          data, and the like, we must address data associated with global
  55.          monitoring, satellite imagery, moving oil spills, subsurface
  56.          geological structures, etc.
  57.      
  58.  
  59.  
  60.     4    Standardized spatial extensions should be of a generic nature,
  61.          that is, without reference to roads, census tracts, ecosystem
  62.          zones, coal seams, etc.  However, users must be able to define
  63.          explicitly such real world concepts in terms of the spatial
  64.          extensions and the underlying SQL data constructs.
  65.  
  66.      
  67.     Our submissions were based directly on the Spatial Archive and
  68.     Interchange Format, SAIF (pronounced 'safe'), the draft standard in
  69.     Canada for modelling and transferring geomatics  information.  SAIF is
  70.     designed to work in a database/telecommunications environment, as well
  71.     as with simple file transfers.  Acceptance at the ISO - SQL level of
  72.     our approach with SAIF is particularly gratifying.
  73.      
  74.     Through the ISO process we have received constructive criticism from
  75.     the Australian Data Base Language Working Group, Oracle Corporation,
  76.     Sierra Systems, MacDonald Dettwiler and Associates, Fulcrum
  77.     Technologies, the Canadian Department of National Defense, IBM and
  78.     others.  With respect to SAIF, we have also benefited from work by the
  79.     Sequoia 2000 project in Berkeley, the U.S. Army Corps of Engineers
  80.     Construction Engineering Research Laboratory, the Centre de Recherche
  81.     en Geomatique at Universite Laval in Quebec, and the Centre for
  82.     Environmental and Resource Information at the University of New
  83.     Brunswick, as well as some of the GIS vendors.
  84.      
  85.     The ISO submission is currently being revised in accordance with the critiques
  86.     and ISO procedures.  We are also planning on releasing SAIF 3.0, to conform
  87.     with the ISO work  (significant changes to SAIF relate to: the way time is
  88.     treated, a more concise way of handling gridded structures, and the
  89.     introduction of multiple inheritance.)  For current data holdings in SAIF's
  90.     binary format, the new version of SAIF will be backwardly compatible with the
  91.     2.0 version.  For those interested in software development, you'll be
  92.     interested in the SAIF ToolBox currently under development.  The ToolBox will
  93.     provide a class library and a set of APIs for the development of applications
  94.     (e.g. translators) based on the SAIF standard.  
  95.      
  96.     If you would like to receive the ISO papers or any of the SAIF
  97.     documentation, please feel free to contact either Henry Kucera
  98.     (hkucera@venus.gov.bc.ca) or me (msondheim@galaxy.gov.bc.ca) through
  99.     Internet or at the address below.
  100.      
  101.     Mark Sondheim,
  102.     Head, Geomatics Unit
  103.     Surveys and Resource Mapping Branch
  104.     1802 Douglas Street
  105.     Victoria, British Columbia, Canada  V8V 1X4
  106.     (FAX: (604) 356-7831)
  107.